<HTML
><HEAD
><TITLE
>Perl 6</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.57"></HEAD
><BODY
CLASS="ARTICLE"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="ARTICLE"
><H1
><A
NAME="AEN1"
>Perl 6</A
></H1
><H2
>The story so far</H2
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="AEN10"
>Why Perl 6</A
></H1
><P
>At TPC 4.0 ("The Perl Conference", run by O'Reilly and Associates in
July 2000) a meeting of Perl 5 developers decided it was time to
start planning for the next major version of Perl: Perl 6.</P
><P
>The reasons for this decision included:</P
><P
></P
><UL
><LI
><P
>Perl 5 internals are becoming increasingly difficult to maintain</P
></LI
><LI
><P
>Perl 6 offered a chance to improve the process by which
Perl itself is developed</P
></LI
><LI
><P
>Increasing "competition" from other languages
(particularly Java, PHP, and Python) prompts us to reassess Perl's
usefulness for real-world development</P
></LI
><LI
><P
>Perl 5 developers have been blessed with 20/20 hindsight
on some decisions (e.g. pseudo-hashes) and would welcome the chance to
make those decisions differently a second time</P
></LI
></UL
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN23"
>Constraints on Perl 5 (Larry's list)</A
></H2
><P
>Larry Wall (the founding father of Perl) offered the following list of
constraints he perceived on Perl 5, at a speech at the Atlanta Linux
Showcase in October 2000.  Emphasised phrases are Larry's; the plain text
parts are my own annotations of Larry's points.</P
><P
></P
><UL
><LI
><P
><I
CLASS="EMPHASIS"
>The need for backward compatibility:</I
>
Perl 5 attempted to be backward compatible with Perl 4, which attempted
to be backward compatible with Perl 3.  This leads to a situation where
legacy or deprecated language constructs are still supported, even if
they really should be thrown out.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>My leisurely mental growth: </I
>
Although most people would be stunned to hear Larry describe his mental
capacities as less than godlike, it is a fact that Perl 5 was Larry's
rewrite, and needed to fit within the scope of his comprehension.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Cultural model with too many bottlenecks:</I
>
Perl 5 development centred around the perl5-porters mailing list
("p5p"), and was presided over by a single "pumpking" (project leader)
at any one time.  </P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Lack of knowledge of the future: </I
>
When Perl 5 was first envisaged, the World Wide Web was only just
gaining in popularity, XML had never been heard of, and numerous other
technologies that we now take for granted were only a dim light on the
horizon.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Lack of round tuition: </I
>
There were a lot of things that might have been done with Perl 5 if
Larry and/or the other developers had got a "round tuit".</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Complexity of the core: </I
>
Perl 5 was a significant departure from Perl 4, and introduced a lot of
new concepts.  The implementation of many of these turned out to be
quite complex, to the point where a potential Perl 5 developer may not
be able to understand it.</P
></LI
><LI
><P
><I
CLASS="EMPHASIS"
>Complacency: </I
>
At the outset of Perl 5, Perl was acknowledged as one of the best and
most widely used tools for toolsmithing on Unix systems, and for CGI
scripting for the World Wide Web.  For some years, Perl rested on its
laurels and failed to address new fields of programming as they rose in
prominence.</P
></LI
></UL
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN48"
>Tinkering with the development process</A
></H1
><P
>Having decided to start work on Perl 6, the first issue addressed was
how to improve the development process.  An examination of the existing
process will underline why this was considered necessary.</P
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN51"
>How it used to be (and still is, for Perl 5)</A
></H2
><P
>Perl 5 development centred around one mailing list, perl5-porters, aka
"p5p".  This mailing list was home to a core group of perl hackers and
an ever-changing procession of hopeful contributors, with Larry
presiding over the whole thing as a benevolent, but mostly uninvolved,
dictator.</P
><P
>The p5p list was very high volume, and many subscribers dropped off it
when they were unable to keep up with the discussions.  For those
without the courage to brave the deluge, a weekly summary was posted on
the web and available by email.  This provided links to threads or
specific posts of significant interest, all of which were available via
a web archive.</P
><P
>As well as being high volume, p5p had a reputation for unfriendliness
and for being the home to some particularly heated flame wars.  Certain
personalities on the list were renowned for the frequency and vehemence
of their flames, and newcomers were often scared away by the
argumentative atmosphere or the cold welcome they received.</P
><P
>More recently, a system of "refereeing" has been introduced, in which a
small group of trusted regulars are charged with keeping the peace.  The
means at their disposal include out-of-band warnings to offenders and
moderation of posters who repeatedly ignore warnings.</P
></DIV
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN57"
>Why change it?</A
></H2
><P
>A number of reasons were given for why the Perl development process
needed changing.  These included:</P
><P
></P
><UL
><LI
><P
>Reverse p5p's bad reputation</P
></LI
><LI
><P
>Give everyone an opportunity to contribute -- not just
the old-timers and Unix users, but also the Windows contingent, the WWW
scripting crowd, and those who use Perl for purposes ranging from
astronomical data-crunching to mainframe applications development</P
></LI
><LI
><P
>Record discussions and decisions for future reference,
so that late joiners could read a clear archive of what had gone before</P
></LI
><LI
><P
>Apply a bit of real project management</P
></LI
><LI
><P
>Foster the kind of working environment that doesn't
drive valuable people away</P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN71"
>How did we make decisions about this?</A
></H2
><P
>Straight after the TPC 4.0 meeting and announcement, a mailing list
called perl6-bootstrap was set up, with the goal of determining what
shape the subsequent process and community should take.</P
><P
>Unfortuneately, the bootstrap phase was given only a couple of weeks to
make decisions, and the first week of that was largely wasted while
travelling TPC attendees returned home, recovered from their jetlag, and
caught up on their email backlogs.</P
><P
>The result was rushed decisions that upset some people.  However, most
of the people were upset because the decisions had been rushed, not
because they were necessarily bad.  Few suggestions were offered that
differed significantly from what we ended up with -- most differences
were in the naming of mailing lists and other such (relative) trivia.</P
></DIV
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN76"
>The shape of Perl 6 development</A
></H2
><P
>Here's what the bootstrap list came up with:
<P
></P
><UL
><LI
><P
>Project manager: Nathan Torkington</P
></LI
><LI
><P
>Working groups, lead by WG chairs</P
><P
></P
><UL
><LI
><P
>Language (Kirrily Robert)</P
></LI
><LI
><P
>Internals (Dan Sugalski)</P
></LI
><LI
><P
>Standard Library (Graeme Barr)</P
></LI
><LI
><P
>Build (Jarkko Hietaniemi)</P
></LI
><LI
><P
>QA (Michael Schwern)</P
></LI
><LI
><P
>Licensing (Bradley Kuhn)</P
></LI
></UL
><P
>Each working group has a mailing list, and may spawn sub-lists
(with chairs for each one) as required.</P
></LI
><LI
><P
>Working groups to develop RFCs describing possible
changes to make in Perl 6.  Note that these are actually "Requests For
Comment", not fixed standards as IETF RFCs tend to be.</P
></LI
><LI
><P
>Larry would create an overall design for Perl 6 based on
the best suggestions to come out of the RFC process.</P
></LI
></UL
></P
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN102"
>Project timeline</A
></H1
><P
></P
><UL
><LI
><P
>July - September: Working groups develop
RFCs</P
></LI
><LI
><P
>October: Larry to work on design based on
RFCs</P
></LI
><LI
><P
>November - December: more detailed design discussion;
sort out teams and process for implementation</P
></LI
><LI
><P
>January: start coding</P
></LI
><LI
><P
>July (TPC 5.0): present Perl 6 alpha</P
></LI
></UL
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN115"
>Where are we now?</A
></H1
><P
></P
><UL
><LI
><P
>350+ RFCs were submitted by September 30th (mostly Language
related)</P
></LI
><LI
><P
>Larry is still working on design</P
></LI
><LI
><P
>Larry gave a talk at ALS outlining some of the design,
and discussing how he's using the RFCs</P
></LI
><LI
><P
>Waiting, waiting, waiting...</P
></LI
><LI
><P
>Meanwhile, we are working on specifying how the detailed
design and implementation process should be managed.  In particular, we
are setting out a format for Perl Design Documents (PDDs) which will
describe specific aspects of the design for the information of new
developers, or for reference purposes for old developers.</P
></LI
><LI
><P
>An apprenticeship program has been discussed to assist
new developers in becoming familiar with the internals and the
development process.</P
></LI
></UL
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN130"
>What will Perl 6 be like?</A
></H1
><P
>Again from Larry's talk at ALS, here is his list of constraints on the
development of Perl 6:</P
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN133"
>Constraints on Perl 6 (Larry's list)</A
></H2
><P
></P
><UL
><LI
><P
>Can Larry understand it? </P
></LI
><LI
><P
>Do people really need the new feature? </P
></LI
><LI
><P
>Can we implement it efficiently and robustly? </P
></LI
><LI
><P
>Does it preclude translation from Perl 5? </P
></LI
><LI
><P
>Does the utility grow faster than the complexity? </P
></LI
><LI
><P
>Does the size grow slower than Moore's Law </P
></LI
><LI
><P
>Must take time to maintain Perl 5 </P
></LI
><LI
><P
>Must take time to design Perl 6 right </P
></LI
></UL
></DIV
><DIV
CLASS="SECT2"
><HR><H2
CLASS="SECT2"
><A
NAME="AEN152"
>Skud's psychic powers predict the future (with help from Larry's talk)</A
></H2
><P
></P
><UL
><LI
><P
>Perl will still be Perl</P
><P
></P
><UL
><LI
><P
>TMTOWTDI ("There's more than one way to do it")
	-- just because one Perl language construct duplicates the
	functionality of another is not sufficient reason to avoid it.</P
></LI
><LI
><P
>Make easy things easy, hard things possible --
	if a feature achieves this, it is in keeping with the Perl
	spirit and is likely to be considered for inclusion.</P
></LI
><LI
><P
>Perl is not Python, Java, C, BASIC, COBOL,
	Lisp... and will not become any of these, despite the loud
	arguments put forward by some proponents of these languages
	during the RFC process</P
></LI
><LI
><P
>... but it should be easy for people from those
	languages to pick up</P
></LI
><LI
><P
>May also be easier to connect directly to those
	languages (e.g. Inline.pm, cleaner XS replacement,
	etc.)</P
></LI
></UL
></LI
><LI
><P
>Language changes</P
><P
></P
><UL
><LI
><P
>Death to global variables! (especially
	punctuation vars such as <TT
CLASS="LITERAL"
>$/</TT
>); these are
	likely to be converted to some kind of OO interface.</P
></LI
><LI
><P
>Deprecated features removed.  For instance, the
	use of <TT
CLASS="LITERAL"
>'</TT
> as a synonym for
	<TT
CLASS="LITERAL"
>::</TT
> will die a peaceful death of old age</P
></LI
><LI
><P
>Non-critical builtins move out to modules,
	including formats, shared memory functions,
	<TT
CLASS="LITERAL"
>gethostbyname</TT
> and friends, etc</P
></LI
><LI
><P
>Easier and safer OO programming</P
></LI
><LI
><P
>Easier functional programming</P
></LI
><LI
><P
>No more typeglobs (but none of their functionality lost)</P
></LI
><LI
><P
>Filehandles become objects</P
></LI
><LI
><P
>Easier interpolation of complex expressions</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>	print "The answer is $obj-&#62;answer()"; </PRE
></TD
></TR
></TABLE
></LI
><LI
><P
>Optional typing of scalars (int, float, etc)</P
><TABLE
BORDER="0"
BGCOLOR="#E0E0E0"
WIDTH="90%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>	my int $answer = 42; 
	my int @array = (1, 2, 3);</PRE
></TD
></TR
></TABLE
></LI
><LI
><P
>Better subroutine parameter specification mechanism</P
></LI
><LI
><P
>A switch statement, based on Damian Conway's
	excellent (and very Perlish) suggested implementation</P
></LI
><LI
><P
>wantarray() becomes a more generic want()</P
></LI
></UL
></LI
><LI
><P
>Standard library changes</P
><P
></P
><UL
><LI
><P
>Greater consistency</P
></LI
><LI
><P
>More applications development support: web, XML,
	CORBA, ???</P
></LI
><LI
><P
>Some stuff moved from the core to the library:
	date/time, shm*, formats, etc</P
></LI
></UL
></LI
><LI
><P
>Internals changes</P
><P
></P
><UL
><LI
><P
>More modular</P
></LI
><LI
><P
>Easier to maintain</P
></LI
><LI
><P
>Much easier to extend</P
></LI
><LI
><P
>Better garbage collection</P
></LI
><LI
><P
>We'll know more when we start on detailed
	design and implementation</P
></LI
></UL
></LI
><LI
><P
>Licensing changes</P
><P
></P
><UL
><LI
><P
>Possible rewrite of the Artistic
	License</P
></LI
></UL
></LI
></UL
></DIV
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN228"
>Where next?</A
></H1
><P
>perl6-meta is in limbo right now; we need impetus, which should come when Larry releases his design</P
><P
>The detailed design and implementation will take a lot
of careful management to happen smoothly. I believe that Nat Torkington
and Dan Sugalski are up to the job, and I hope to be able to help out as well.</P
><P
>Will an alpha be ready for TPC 5.0?  Who knows.  I hope we'll have
something to show off, but I also hope the world understands what
"alpha" means, and doesn't expect a fully fledged Perl, because it won't
be. I'm guessing we'll present a design, but no working code beyond
individual modules of no use in the real world.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN233"
>Long term...</A
></H1
><P
>Perl 5 will continue to exist and be maintained.  Perl 5.7 is under
active development now, 5.8 is ahead of us, and there may be more 5.X
versions beyond that.  ActiveState have committed to supporting Perl 5
after Perl 6 is released, and a few individual developers have
said they will continue to work on Perl 5 for as long as necessary.</P
><P
>It will be at least 2 years until a stable Perl 6, and even longer until
it's widespread.  For comparison, consider that there are
<I
CLASS="EMPHASIS"
>still</I
> people using Perl 4 more than five years
after the release of the much more featureful Perl 5.  Of course,
popular uptake of Perl 6 depends on it being as much of an improvement
over Perl 5 as Perl 5 was over Perl 4.</P
><P
>Nevertheless, this is not worrying us.  We hope to do it right, rather
than fast.</P
></DIV
><DIV
CLASS="SECT1"
><HR><H1
CLASS="SECT1"
><A
NAME="AEN239"
>More information</A
></H1
><P
></P
><UL
><LI
><P
>http://www.perl.org/perl6/</P
></LI
><LI
><P
>http://dev.perl.org/</P
></LI
></UL
></DIV
></DIV
></BODY
></HTML
>